Up to now, connecting multiple communications apparatuses, each of which is provided with a communications function, to enable communicating via a network and building various systems have been carried out. As an example, there is a so-called electronic commerce system such that orders for products are transmitted from a computer such as a PC which functions as a client apparatus and those orders are received in a server apparatus enabled to communicate with this client apparatus over the Internet. Moreover, a system is being proposed such that each of the various electronic apparatuses is made to have a function of the client apparatus or the server apparatus so as to be connected via a network, and remote control of the electronic apparatuses is performed by means of mutual communications.
In building such a system, it is important to confirm when communicating, for instance, whether the communications counterparty is appropriate, or whether information having been transmitted is being manipulated. Moreover, especially when communicating over the Internet, there is also a demand for making sure that, when transmitting confidential information, the contents are not viewed stealthily, as the information often passes through unrelated computers before reaching the communications counterparty. Then, as a communication protocol that responds to such a demand, for example a protocol called SSL (Secure Socket Layer) has been developed and is being widely used. Communicating using this protocol enables combining a public-key encrypting method and a common-key encrypting method, authenticating the communications counterparty, as well as preventing manipulating and eavesdropping by means of encrypting the information. Moreover, also at the communications-counterparty side, authenticating an apparatus of a communications source having requested communications is enabled.
As technologies related to such authentication using the SSL and the public-key encrypting, there are, for example, those as described in the Patent Documents 1 and 2.
Patent Document 1    JP 2002-353959A
Patent Document 2    JP 2002-251492A
Herein, a procedure for communicating when performing mutual authentication according to this SSL is described, focusing on an authentication process. FIG. 18 is a flowchart of a process for each apparatus when a communications apparatus A and a communications apparatus B are performing mutual authentication according to the SSL, together with information used in the process.
As illustrated in FIG. 18, when performing mutual authentication according to the SSL, it is necessary to have stored in both communications apparatuses a root-key certificate, a private key and a public-key certificate. This private key is a private key that is issued to each apparatus by a CA (Certificate Authority), and the public-key certificate is one which the CA has provided as a digital certificate as the CA affixes a digital signature to a public key corresponding to the private key so as to be made a digital certificate. Moreover, the root-key certificate is one which the CA has provided as a digital certificate with a root key corresponding to a private root-key that the CA has used for the digital signature so as to be made a digital certificate.
FIGS. 19A and 19B illustrate a relationship among these keys.
As illustrated in FIG. 19A, a public key A is configured with a key main-body for decrypting a document encrypted using a private key A, and bibliographical information including information on a source (CA) of the public key and an expiry date, etc. Then, the CA, in order to indicate that the key main-body and the bibliographical information are not manipulated, has a hash value obtained by hashing the public key A encrypted using the private root-key for providing to a client public-key as a digital signature. Moreover at this time, identifying information identifying the private root-key is added as signing-key information to bibliographical information on the public key A. Then, the public-key certificate being provided this digital signature is a public-key certificate A.
When using this public-key certificate A for an authentication process, the digital signature included therein is decrypted using a key main-body of the root key as a public key corresponding to the private root-key. When this decrypting is performed successfully, it is known that the digital signature surely has been provided by the CA. Moreover, when the hash value obtained by hashing a part of the public key A, and the hash value obtained by decrypting match, it is known that the key main-body also has not been damaged or manipulated. Furthermore, when the received data can be decrypted successfully using this public key A, it is known that the data are those transmitted from a holder of the private key A.
Herein, in order to perform an authentication, while it is necessary to store a root key in advance, this root key, as illustrated in FIG. 19B, is also made to be stored as a root-key certificate with the CA having provided the digital signature. This root-key certificate is in a form of a self-signature such that decrypting of a digital signature with a public key contained in the certificate itself is enabled. Then, when using the root key, the digital signature is decrypted by using the key main-body included in the root-key certificate for comparing with the hash value obtained by hashing the root key. When these are matched, it is confirmed that the root key is not damaged, etc.
The flowchart in FIG. 18 is now described. It is noted that, in FIG. 18, with arrows between two flowcharts denoting data transfer, the transmitting side performs a transfer process in a step originating the arrow, and the receiving side, once receiving the information, performs a process in a step to which the arrow points. Moreover, when the process in each step is not successfully completed, a response indicating an unsuccessful authentication is returned at that time so as to suspend the process. The same applies when the response indicating the unsuccessful authentication is received from the communications counterparty, or when a timeout of the process is reached, etc.
Herein, assuming that a communications apparatus A requests communications with a communications apparatus B, when performing the request, a CPU of the communications apparatus A executing required control programs starts the process in the flowchart illustrated at the left in FIG. 18. Then, in Step S11, a connection request is transmitted to the communications apparatus B.
On the other hand, a CPU of the communications terminal B, once receiving the connection request, executing required control programs, starts the process in the flowchart illustrated at the right in FIG. 18. Then, in Step S21 a first random number is generated for encrypting using a private key B. Then, in Step S22 the encrypted first random number and a public-key certificate B are transmitted to the communications apparatus A.
At the communications apparatus A side, once receiving this, Step S12 confirms the validity of the public-key certificate B using a root-key certificate.
Then once having confirmed validity, in Step S13, the first random number is decrypted using a public key B included in the received public-key certificate B. When the decrypting is successful, confirming that the first random number has surely been received from a subject of issuance of the public-key certificate B is enabled.
Subsequently, in Step S14 further a second random number and a common-key seed are generated. The common-key seed may be generated, for example, based on data transacted in prior communications. Then, in Step S15 the second random number is encrypted using a private key A, and the common-key seed is encrypted using the public key B, for transmitting these along with a public-key certificate A to a server apparatus. The encrypting of the common-key seed is performed in order to make sure that the common-key seed is not known to an apparatus other then the communications counterparty.
Moreover, in the next Step S17, a common key for use in encrypting subsequent communications is generated from the common-key seed generated in Step S14.
At the communications apparatus B side, once receiving data having been transmitted in Step S16 from the communications apparatus A, in Step S23 the validity of the public-key certificate A is confirmed using a root-key certificate. Then once confirmed, in Step S24, the second random number is decrypted using the public key A included in the received public-key certificate A. When the decrypting is successful herein, confirming that the second random number is surely received from a subject of issuance of the public-key certificate A is enabled.
Subsequently, in Step S25 the common-key seed is decrypted using a private key B. In the processes thus far, the common-key seed has been shared at the communications apparatus A side and at the communications apparatus B side. Then, the common-key seed does not become known to an apparatus other than the communications apparatus A having generated the seed and the communications apparatus B having the private key B. When the processes thus far are successful, also at the communications apparatus B side in Step S26, a common key for use in encrypting subsequent communications is generated from the common-key seed obtained in the decrypting.
Then, once the processes of Step S17 at the communications apparatus A side and Step S26 at the communications apparatus B side are completed, a success of authentication and an encrypting method for use in subsequent communications are mutually confirmed and the process regarding the authentication is terminated assuming that subsequent communications are performed with the encrypting method using the common key generated. It is noted that, in this confirmation, a response from the communications apparatus B that an authentication has succeeded is also included. The processes as described above enable mutual establishing of communications, and, subsequently, encrypting of data by means of a common-key encrypting method, using the common key generated in Step S17 or S26 so as to perform the communications.
Performing such processes enables the communications apparatuses A and B to securely share a common key and to establish a route for communicating securely.
It is to be noted that, in the processes as described above, it is not mandatory to encrypt the second random number with the public key A, and to transmit the public-key certificate A to the communications apparatus B. In this case, the processes of Steps S23 and S24 at the communications apparatus B side are not needed so that the process becomes as illustrated in FIG. 20. In such a way, while the communications apparatus B cannot authenticate the communications apparatus A, this process is sufficient when only the communications apparatus A authenticating the communications apparatus B suffices. Then in this case, it is necessary to have only the root-key certificate, and not the private key A and the public-key certificate A, stored in the communications apparatus A. Moreover, it is not necessary to have the root-key certificate stored in the communications apparatus B.
Now, when performing the authentication process as described above, two levels are possible for the authentication criteria. A first level determines whether equipment of a communications counterparty fulfills certain criteria such as whether it is supplied from the same vendor, or whether it has passed a certain test, whereas a second level specifies an individual equipment unit of the communications counterparty.
Then, when performing the first-level authentication, it suffices to have a common set of a public-key certificate and a private key stored in equipment fulfilling certain criteria, to use the stored common set to perform the authentication at the time of SSL communications and for the communications counterparty to be able to confirm as surely that it is an apparatus of issuance of the public-key certificate. Therefore, there is no need to replace equipment-specific identifying information (ID), etc.
Moreover, even when performing the second level authentication, it is possible that, after establishing a secure communications route using, for example, the same key as in the case of the first-level authentication as described above, an ID is made to be transmitted in order to specify a communications counterparty, for use in the authentication.
Herein, when operating a communications system for having communications conducted between communications apparatuses, in case it is envisioned that there is to be no operator near the apparatuses, there is a demand such that specifying of an apparatus is performed with the communications. Then, in order to fulfill such a demand, a mechanism for guaranteeing that the apparatus specified with the communications is surely the apparatus is needed. In other words, the second-level authentication as described above is needed.
However, in the method as described above such that after the secure communications route is established the ID is made to be transmitted so as to specify the communications counterparty, a need arises to separately manage the ID with an application from the authentication process according to the SSL.
Moreover, when the common public-key certificate and the private key are leaked, a third party having obtained the leaked information may disguise itself as any equipment having a detectable ID, seriously compromising the security of the communications. Then in this case, the security of the communications cannot be recovered unless keys of all equipment units are updated, the task requiring a great deal of effort.
Then, in order to solve this issue, a public-key certificate and a private key are issued per apparatus, and information identifying the apparatus is provided in bibliographical information of the public-key certificate, such that when confirming the validity of the public-key certificate the identifying information having been included in the bibliographical information is referred to so as to confirm that a counterparty having transmitted the certificate (a subject apparatus of issuance of the certificate) is an appropriate communications counterparty. In such a case, as a different pair of the public-key certificate and the private key is made to be stored for each apparatus, even when a key of one equipment unit is leaked, the third party disguising is possible only as the one equipment unit, and when the key of the one equipment unit is updated, maintaining the communications again in a secure state is enabled.
Now, when authenticating an apparatus, as a matter of course an authentication that specifies the apparatus is needed, which is different from authentication that specifies an operator of a Web browser, etc. Thus, while there is a need to have a digital certificate stored in advance in the apparatus, when a component storing the digital certificate is replaced, the digital certificate ends up being dropped with the component. Thus, the authentication of the apparatus cannot be performed. Therefore, when using a public-key certificate provided with information identifying an apparatus, a problem would occur when a need arises to replace a component storing the digital certificate due to damage or a failure, etc.
Although there is no problem when the digital certificate is still being stored in a replaced component, it is not desirable that identifying information for use in the replacing component be changed, in order to specify an equipment unit or a user. However, in order to have a public-key certificate provided in the replacing component with the same identifying information as the replaced component, information identifying an apparatus to be receiving the replacing component at the time of manufacturing is needed, making it impossible to have in advance a component ready to be the replacing component having recorded a new public-key certificate. Therefore, there is a problem such that manufacturing is done as needed only after the apparatus requiring the replacing component becomes known, which imposes an extremely inefficient production system.
Moreover, there is a problem such that as components cannot be supplied speedily, the apparatus needs to be kept for a certain period in a state of not being able to successfully perform an authentication process according to the SSL, making it impossible to maintain, during the period of replacing a component, a secure communications channel for the apparatus.
While it is possible to have separately stored the public-key certificate and the private key after replacing the component, in a state without such stored information, successful performing of the authentication process according to the SSL cannot be done, making impossible the maintaining of a secure communications route for the apparatus having replaced a component. Thus, in order to securely distribute a new public-key certificate, etc., there is a need to store it in a recording medium so as to be sent by post to an installation site of the apparatus or brought by a representative servicing the replacing of the component. However, even in having this recording medium ready, there is a problem that is the same as in the case of component manufacturing as described above.
Furthermore, in order to prevent a disguising, etc. of an apparatus, for the digital certificate, there is a need to prevent a malicious user replacing, reading or registering, and a need to prevent a general user from updating a digital certificate, making difficult the confirming of privileges when manually setting the digital certificate.